Your question survived the error clinic. Today it becomes something you can actually execute — and something that can end.
Turn one repaired sentence into a bounded, checkable plan.
A project is defined as much by what it excludes as by what it does.
Your notebook, open at Section 3 — with the v2 statement you repaired last class.
Assignment 1 · 10 marks · CO1 · due at the Quiz 1 slot.
Dr. Mohsin Furkh Dar · School of Computer Science · 5th Semester
B.Tech CSE · 55 minutes
Navigate: → / Space next · ← back · O slide list ·
D dark mode · F full screen
Today (I.6): that sentence acquires a boundary, a set of objectives, and a hypothesis that can lose.
“How will I know when I am finished?”
Every student project that runs to the last night has the same defect: nobody ever wrote down what was not included. Without that line, there is always one more feature, one more baseline, one more dataset — and the report is written in a panic at 3 a.m.
Scope is not paperwork. It is the mechanism by which a project can terminate.
Founded by Mitch Kapor — the person behind Lotus 1-2-3, one of the most successful applications ever written. Funded generously. Staffed with senior engineers. The goal: an open-source personal information manager that would reinvent how people handle email, calendar and tasks.
The project was documented from the inside by a journalist for three years, and the book that resulted — Dreaming in Code (2007) — is largely the story of a team that could not settle what the product was not.
Version 1.0 arrived in 2008, years late and far smaller in ambition than the vision. Development wound down shortly after.
The engineers were excellent. The money was there. The vision was inspiring.
So what exactly is the missing artefact — the one document that would have changed the outcome?
“Better project management” is not an answer in this course. Name the sentence that was never written.
Result: entries from tens of thousands of teams across the world, a winning solution in 2009, and a body of published knowledge on ensembles and matrix factorisation that outlived the contest.
1 · The winning ensemble was never fully deployed. Netflix reported that the engineering cost of the full solution outweighed the benefit. The research question ("can RMSE be cut by 10%?") was answered exactly as posed — it simply was not the same question as "should we ship this?" A scope is a promise about what you will answer, not a promise that the answer will be adopted.
2 · The data had a limitation nobody declared. In 2007 researchers showed that "anonymised" ratings could be re-identified by matching against public reviews. A planned sequel was cancelled. An undeclared limitation does not stay undeclared — it is found by someone else, later, publicly.
Chandler had unlimited ambition and no boundary, and produced almost nothing. The Prize had a narrow boundary and produced a field's worth of knowledge. The boundary is not what limits the contribution — it is what makes one possible.
| 0–7 | Chandler vs the Netflix Prize |
| 7–17 | Scope · delimitations · limitations + sorting drill |
| 17–29 | General vs specific objectives; verb clinic; objective builder |
| 29–37 | Questions, hypotheses, and the chain that must hold |
| 37–49 | Worksheet — your own one-page plan + peer check |
| 49–55 | Assignment 1 brief, notebook task, next lecture |
Chosen by you. Stated as inclusions: which population, which tasks, which datasets, which time window, which platforms.
“Three crops — tomato, potato, maize. Field-captured images, Jan–Mar 2026. Android 11+.”
Job: tells the reader what the claim will cover.
Chosen by you, with a reason. The exclusions that make the project finite.
“No multi-disease co-infection — no labelled data exists. No yield prediction — outside the question.”
Job: the wall that stops your supervisor, your examiner and you at 2 a.m. from expanding the project.
Not chosen by you. Constraints you must live with: sample size, hardware, data access, one institution's data, a single annotator.
“One district only; n = 30 by ethics approval; a single GPU, so no model above 3 B parameters.”
Job: declared, they protect the claim. Hidden, they destroy it at the viva.
The one-line test: Scope = “we study …” · Delimitation = “we deliberately do not study …, because …” · Limitation = “we could not …, therefore the claim holds only for …”
Score: 0 / 9 · S = scope, D = delimitation, L = limitation
WEAK
“We will not consider multilingual inputs.”
Reads as an oversight. An examiner asks: did you decide this, or did you forget?
STRONG
“We exclude multilingual inputs. No annotated corpus exists for the target dialect, and building one would consume the full project budget. The question we ask is about lighting robustness, and language does not bear on it.”
Three ingredients: what is excluded · why · why the exclusion does not damage the claim.
It is week nine, 2 a.m., and you think of a brilliant addition: “what if we also tried it on X?”
Open your delimitation box. If X is listed there with a reason, you are done thinking; go to sleep. If it is not listed, you will spend three days on it, and those three days come out of your writing week.
That is what the box is for. It is not for the examiner. It is a pre-commitment device you write while calm, to be obeyed while panicking.
Same logic as pre-committing your metric in Lecture I.5 — decisions made before the pressure arrives are the honest ones.
“To measure and explain the accuracy degradation of a PlantVillage-trained classifier on field-captured images for three Uttarakhand crops.”
One sentence. One per project. If you need two, you have two projects — pick one and delimit the other away.
Three to five. If all of them are completed, the general objective is necessarily achieved. If that is not true, the set is wrong: something is missing, or something does not belong.
| # | Specific objective | Artefact it produces |
|---|---|---|
| O1 | Assemble a field-captured evaluation set of 1,200 images across three crops | Table 1 — dataset summary |
| O2 | Reproduce the published baseline within 2 points of the reported accuracy | Table 2 — reproduction check |
| O3 | Quantify the top-1 accuracy drop from lab to field images | Figure 1 — drop by crop |
| O4 | Attribute the drop across background clutter, illumination and blur | Table 3 — ablation |
| O5 | Measure on-device latency on a sub-$80 handset | Figure 2 — latency profile |
One objective → one experiment → one table or figure. An objective that produces no artefact is a wish.
For each verb, decide as a class: could a stranger tell, from your report alone, whether you did it? Then click to test.
Click a verb.
Use these: measure · compare · quantify · characterise · evaluate · attribute · benchmark · replicate · classify. Each names an observable action with an output.
Never these: understand · explore · study · investigate · look into · gain insight into · learn. Each names a state of mind, and no examiner can check a state of mind.
YOUR SPECIFIC OBJECTIVE
—
Fill all four boxes. Then ask the only question that matters: what experiment discharges this, and where does its output appear in the report?
Sub-questions are not decoration: each one should correspond to a specific objective, and therefore to an experiment.
RQ (main): How much accuracy does a PlantVillage-trained classifier lose on
field-captured images of three Uttarakhand crops, and what accounts for the loss?
RQ1: What is the top-1 accuracy gap between lab and field images, per crop?
RQ2: How much of the gap is attributable to illumination, clutter and blur
respectively?
RQ3: Does illumination normalisation recover a measurable share of the gap, and at what
latency cost on a low-end handset?
Notice: RQ1 asks how much (descriptive), RQ2 asks why (explanatory), RQ3 asks what if (interventional). Three different kinds of evidence — which is exactly what Lecture I.7 is about.
| Question | Interrogative · neutral · takes no risk |
| Hypothesis | Declarative · specific · takes a risk, and names in advance the result that would defeat it |
A directional hypothesis ("will be lower by more than 10 points") is stronger than a non-directional one ("will differ"), because it can be wrong in a specific way. The more ways a claim can fail, the more it is worth when it survives.
Where statistics enter: state H₀ (no difference) and H₁ (your directional claim), the test you will use, and the threshold — before you run anything. Writing the hypothesis after seeing results has a name, HARKing, and it is the E7 error from last class in a lab coat. Unit III returns to it.
Pick a version.
Start at the right. Take your claim and walk backwards, saying out loud which metric supports it, which data produced the metric, which method produced the data. The first step where you have to say “well, sort of” is your broken link.
Every viva question is secretly a link in this chain. “How do you know?” is metric → claim. “Why this experiment?” is objective → method. “Would this hold elsewhere?” is data → claim.
Case 1 of 4 · Correct: 0
—
Click the arrow where the chain first fails. In every case the individual pieces are competent work — the failure is only in the join.
“Study the literature.” “Learn PyTorch.” “Collect data.” These are things you do on a Tuesday, not results anyone can check. Repair: name the outcome the activity produces — “characterise the reported accuracy of five published models on X (Table 1)”.
Seven specific objectives in a twelve-week project, each needing an experiment and a write-up. Repair: keep three, and move the rest into your delimitations — where they become evidence of judgement rather than evidence of over-reach.
The objective says attribute or explain, but the plan only measures an overall difference. Explanation needs an ablation or a controlled intervention. Repair: either add the ablation, or downgrade the verb to quantify — honestly.
Inclusions listed, delimitations absent. The project has no state in which it is finished. Repair: write three exclusions with reasons, today, before the work starts. This is the Chandler failure, in miniature.
Total runs = methods × datasets × seeds × (1 + ablations)
· Hours = runs × hours per run.
TOTAL RUNS
36
COMPUTE HOURS
54
VERDICT
—
Try it: add one extra baseline. The cost does not go up by
one run — it goes up by datasets × seeds × (1+ablations) runs. This is why "we'll also
compare against X" is never a small request, and why every added comparison belongs in the plan or in the
delimitations.
Your reviewer answers only these three questions, out loud, using nothing but what you wrote:
Reviewers: you are checking traceability, not ambition. A modest plan whose chain holds beats an impressive one that breaks at the first arrow.
Due: at the Quiz 1 slot — 25 August (CCVT) / 26 August (Full Stack AI). Bring it printed and hand it in before the quiz starts.
| Criterion | Marks |
|---|---|
| Problem statement — bounded, situated, falsifiable | 2 |
| Scope, delimitations (with reasons) and limitations | 2 |
| Objectives — measurable verbs, one artefact each, set discharges the general objective | 2 |
| Questions and hypotheses — neutral RQs, directional H₁, refutation stated | 2 |
| Feasibility card with evidence + three real references | 1.5 |
| Format, word limit, clarity | 0.5 |
Automatic deductions: an objective beginning understand / explore / study; a hypothesis with no refutation condition; a scope section with no exclusions; a statement whose claim cannot be traced to a metric.
A project ends because someone wrote down what it was not.
Sections touched today: 3 · Problem Statement (the scope box), 4 · Research Questions and 5 · Research Objectives. As always: add, never overwrite.
\version{3}{2026-08-20}{after Lecture
I.6}.methods ×
datasets × seeds × (1+ablations) × hours, and whether it fits.Investigative approaches: analytical, experimental, simulation-based and design-science. You will have a question and a hypothesis; I.7 asks what kind of evidence could settle them — and why choosing a method because it is familiar is the most expensive mistake left in Unit I.
Sources: Rosenberg, Dreaming in Code (2007) — Chandler · Netflix Prize rules and the 2009 grand-prize announcement · Narayanan & Shmatikov (2008), “Robust De-anonymization of Large Sparse Datasets”.